1. Field of the Invention
This invention relates to computer databases. Specifically, this invention relates to methods of indexing database records which contain information describing the position, size and shape of objects in two and three-dimensional space.
2. Description of the Related Technology
The purpose of a data structure is to organize large volumes of information, allowing the computer to selectively process the data structure's content. The motivation for this is simple: you always have more data than your time requirements, processor speed, main memory and disk access time allow you to process all at once. Depending on the nature of the data and application, data organizing strategies may include partitioning the content into subsets with similar properties or sequencing the data to support indexing and hashing for fast random access. Databases and database management systems extend these concepts to provide persistent storage and transaction controlled editing of the structured data.
Spatial data such as that describing a two-dimensional map is no different in its need for efficient organization. Map data is particularly demanding in this regard. A comprehensive street map for a moderate sized community may consist of tens to hundreds of thousands of individual street segments. Wide area maps of LA or New York may contain millions of segments. The content of each map data object can also be some what bulky. For example, a record for an individual street segment may include the coordinates of its end points, a usage classification, the street name, street address ranges, left and right side incorporated city name and postal codes.
However, spatial data at its core poses a particularly vexing organizational problem because it tries to organize objects within two-dimensional space. Spatial coordinates consist of two (or more) values which are independent, but equally important for most spatial queries. Established data structures and database methods are designed to efficiently handle a single value, and not representations of multi-dimensional space.
This difficulty can be illustrated by considering the problem of creating an application which presents a small window of map data (for instance, the square mile surrounding a house) from a database of a few hundred thousand spatial objects (a map of the city surrounding the house). The motivation for doing this is really two fold: first, the typical resolution of a computer monitor is limited, allowing only a certain amount information to be expressed. Secondly, even if all the data fit within the monitor, the data processing time to calculate this much information (fetching, transforming, clipping, drawing) would be far too long for the average personal computer.
To solve this problem, it is advantageous to find all of the street segments which appear in the “window” that will be generated on the monitor, and avoid as many as possible which do not. Thus, all objects which are within a particular range of x-coordinate (or longitude) values and y-coordinate (or latitude) values will be gathered. This problem is generally known as rectangular window retrieval, and is one of the more fundamental types of spatial queries. This method will be used in the following sections as a method for gauging the effectiveness of each of the following organizational methods.
The most heavily researched and commonly used spatial data structures (data structures used to organize geographic and geometric data) rely on the concept of tile-based hierarchical trees. A tile in this context is a rectangular (or other regularly or irregularly shaped) partitioning of coordinate space, wherein each partition has a distinct line separating one tile from another so that no single point in the coordinate system lies within more than one tile. A hierarchical tree is one structure for dividing coordinate space by recursively decomposing the space into smaller and smaller tiles, starting at a root that represents the entire coordinate space. In this system, a “hard edge” between tiles means that every point in the space resides exactly one tile at each level of the hierarchy. No point can coexist in more than one tile.
One example of a well-known hierarchical tree is the quad-tree data structure. In one example, the quad-tree could represent the surface of the Earth. At the root of the quad-tree is a node representing the entire surface of the Earth. The root, in turn, will have four children representing each quadrant of Latitude and Longitude space: east of Greenwich and north of the Equator, east of Greenwich and south of the Equator, west of Greenwich and north of the Equator and finally, west of Greenwich and south of the equator. Points on Greenwich and the Equator are arbitrarily defined to be in one quadrant or the other. Each of these children are further subdivided into more quadrants, and the children of those children, and so on, down to the degree of partitioning which is required to support the volume and density of data which is to be stored in the quad-tree.
The principle problem with quad-tree structures is that they are unbalanced. Because each node in the tree has a limited data storage capacity, when that limit is exceeded, the node must be split into four children, and the data content pushed into lower recesses of the tree. As a result, the depth of a quad-tree is shallow where the data density is low, and deep where the data density is high. For example, a quad-tree used to find population centers on the surface of the Earth will be very shallow (e.g., have few nodes) in mid-ocean and polar regions, and very deep (e.g., have many nodes) in regions such as the east and south of the United States.
Since quad-trees are inherently unbalanced, the rectangular window retrieval behavior of a quad-tree is difficult to predict. It is difficult for software to predict how many nodes deep it may have to go to find the necessary data. In a large spatial database, each step down the quad-tree hierarchy into another node normally requires a time-consuming disk seek. In addition, more than one branch of the tree will likely have to be followed to find all the necessary data. Second, when the content of the data structure is dynamic, efficient space management is problematic since each node has both a fixed amount of space and a fixed regional coverage. In real world data schemes, these two rarely correspond. There are several variations on the quad-tree which attempt to minimize these problems. However, inefficiencies still persist.
So far, data structures containing points have only been discussed where each spatial object comprises a single set of coordinates. Lines, curves, circles, and polygons present a further complexity because they have dimensions. Therefore, these objects no longer fit neatly into tile based data structures, unless the tiling scheme is extremely contrived. There will always be some fraction of the objects which cross the hard edged tile boundaries from one coordinate region to another. Note that this fact is true regardless of the simplicity of an object's description. For example, a line segment described by its two end points, or a circle described by its center point and radius.
A simple, and commonly used way around this problem is to divide objects which cross the tile boundaries into multiple objects. Thus, a line segment which has its end points in two adjacent tiles will be split into two line segments; a line segment which starts in one tile, and passes through fifty tiles on its way to its other end will be broken into fifty-two line segments: one for each tile it touches.
This approach can be an effective strategy for certain applications which are read-only. However, it is a poor strategy for data structures with dynamic content. Adding new data objects is relatively simple, but deleting and modifying data are more difficult. Problems arise because the original objects are not guaranteed to be intact. If a line segment needs to be moved or removed, it must somehow be reconstituted so that the database behaves as expected. This requires additional database bookkeeping, more complicated algorithms and the accompanying degradation in design simplicity and performance.
Another general problem related to organizing multidimensional objects is that many of these objects are difficult to mathematically describe once broken up. For example, there are numerous ways in which a circle can overlap four adjacent rectangular tiles. Depending on placement, the same sized circle can become two, three or four odd shaped pieces. As with a heavily fragmented line segment, the original “natural” character of the object is effectively lost.
An alternate strategy is to use indirection, where objects which cross tile boundaries are multiply referenced. However, each reference requires an extra step to recover the object, and the same object may be retrieved more than once by the same query, requiring additional complexity to resolve. When the number of objects in the database becomes large, this extra level of indirection becomes too expensive to create a viable system.
Another strategy used with quad-trees is to push objects which cross tile boundaries into higher and higher levels of the tree until they finally fit. The difficulty with this strategy is that when the number of map objects contained in the higher nodes increases, database operations will have to examine every object at the higher nodes before they can direct the search to the smaller nodes which are more likely to contain useful information. This results in a tremendous lag time for finding data.
Query Optimization in a Conventional DBMS
As discussed above, data which describes the position, size and shape of objects in space is generally called spatial data. A collection of spatial data is called a Spatial Database. Examples of different types of Spatial Databases include maps (street-maps, topographic maps, land-use maps, etc.), two-dimensional and three-dimensional architectural drawings and integrated circuit designs.
Conventional Database Management Systems (DBMS) use indexing methods to optimize the retrieval of records which have specific data values in a given field. For each record in the database, the values of the field of interest are stored as keys in a tree or similar indexing data structure along with pointers back to the records which contain the corresponding values.
DATABASE TABLE 1 shows an example of a simple database table which contains information about former employees of a fictional corporation. Each row in the table corresponds to a single record. Each record contains information about a single former employee. The columns in the table correspond to fields in each record which store various facts about each former employee, including their name and starting and ending dates of employment.
DATABASE TABLE 1The FormerEmployee database table.NameStartDateEndDateOther ...P. S. Buck6/15/928/2/95Willy Cather1/27/936/30/93Em Dickinson9/12/9211/15/92Bill Faukner7/17/942/12/95Ernie Hemmingway6/30/915/14/93H. James10/16/9112/4/92Jim Joyce11/23/925/8/93E. A. Poe1/14/934/24/95
EXAMPLE QUERY 1 shows a SQL query which finds the names of all former employees who started working during 1993. If the number of records in the former employee database were large, and the query needs to be performed on a regular or timely basis, then it might be useful to create an index on the StartDate field to make this query perform more efficiently. Use of a sequential indexing data structure such as a B-tree effectively reorders the database table by the field being indexed, as is shown in DATABASE TABLE 2. The important property of such sequential indexing methods is that they allow very efficient search both for records which contain a specific value in the indexed field and for records which have a range of values in the indexed field.